I'm sure I'm confused, but... It seems logical that RST sequence numbers should be ignored. RSTs are usually sent to abort a hosed connection, one in which it is likely the sequence numbers are already out of whack. No. Here's an excerpt from section 3.4 of RFC 793, the TCP spec: Reset Processing In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN. The receiver of a RST first validates it, then changes state. If the receiver was in the LISTEN state, it ignores it. If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state, otherwise the receiver aborts the connection and goes to the CLOSED state. If the receiver was in any other state, it aborts the connection and advises the user and goes to the CLOSED state. The preceeding paragraphs describe when to send an RST, and how to create the sequence number for it. If you read them, you'll see that most packets that can elicit an RST carry an SEQ field; it can be used to generate the sequence number for the RST. We're getting a bit far afield here, and I won't pursue the topic further save to note that TCP's behavior is carefully crafted, and trying to change one small piece of it can have unintended side-effects. For example, I'm not at all convinced that it's safe -- from a non-security perspective -- to use random initial sequence numbers. See section 3.3 of the RFC for the rationale for the current behavior.